Network Working Group D. McMaster 
Request for Comments: 1516 SynOptics Communications, Inc. 
Obsoletes: 1368 K. McCloghrie 
Hughes LAN Systems, Inc. 

September 1993 


Definitions of Managed Objects 
for IEEE 802.3 Repeater Devices 


Status of this Memo 


This RFC specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" for the standardization state and status 
of this protocol. Distribution of this memo is unlimited. 

Abstract 


This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community. 
In particular, it defines objects for managing IEEE 802.3 10 
Mb/second baseband repeaters, sometimes referred to as "hubs." 
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1. The Network Management Framework 


The Internet-standard Network Management Framework consists of 
three components. They are: 


o STD 16, RFC 1155 which defines the SMI, the mechanisms used for 
describing and naming objects for the purpose of management. 
STD 16, RFC 1212 defines a more concise description mechanism, 
which is wholly consistent with the SMI. 


o STD 17, RFC 1213 defines MIB-II, the core set of managed objects 
for the Internet suite of protocols. 


o STD 15, RFC 1157 which defines the SNMP, the protocol used for 
network access to managed objects. 


The Framework permits new objects to be defined for the purpose of 
experimentation and evaluation. 


1.1. Object Definitions 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. Objects in the MIB are 
defined using the subset of Abstract Syntax Notation One (ASN.1) 
defined in the SMI. In particular, each object object type is named 
by an OBJECT IDENTIFIER, an administratively assigned name. The 
object type together with an object instance serves to uniquely 
identify a specific instantiation of the object. For human 
convenience, we often use a textual string, termed the descriptor, to 
refer to the object type. 


2. Overview 


Instances of the object types defined in this memo represent 
attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by 
Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE 
802.3/I1SO 8802-3 CSMA/CD standard [7]. 


These Repeater MIB objects may be used to manage non-standard 
repeater-like devices, but defining objects to describe 
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implementation-specific properties of non-standard repeater-like 
devices is outside the scope of this memo. 


The definitions presented here are based on the IEEE draft standard 
P802.3K, "Layer Management for 10 Mb/s Baseband Repeaters" [8]. 
Implementors of these MIB objects should note that [8] explicitly 
describes when, where, and how various repeater attributes are 
measured. The IEEE document also describes the effects of repeater 
actions that may be invoked by manipulating instances of the MIB 
objects defined here. 


The counters in this document are defined to be the same as those 
counters in the IEEE 802.3 Repeater Management draft, with the 
intention that the same instrumentation can be used to implement both 
the IEEE and IETF management standards. 


2.1. Terminology 
2.1.1. Repeaters, Hubs and Concentrators 


In late 1988, the IEEE 802.3 Hub Management task force was chartered 
to define managed objects for both 802.3 repeaters and the proposed 
1OBASE-FA synchronous active stars. The term "hub" was used to cover 
both repeaters and active stars. 


In March, 1991, the active star proposal was dropped from the 
10BASE-F draft. Subsequently the 802.3 group changed the name of the 
task force to be the IEEE 802.3 Repeater Management Task Force, and 
likewise renamed their draft. 


The use of the term "hub" has led to some confusion, as the terms 
"hub," “intelligent hub," and "concentrator" are often used to 
indicate a modular chassis with plug-in modules that provide 
generalized LAN/WAN connectivity, often with a mix of 802.3 repeater, 
token ring, and FDDI connectivity, internetworked by bridges, 
routers, and terminal servers. 


To be clear that this work covers the management of IEEE 802.3 
repeaters only, the editors of this MIB definitions document chose to 
call this a "Repeater MIB" instead of a "Hub MIB." 


2.1.2. Repeaters, Ports, and MAUs 
The following text roughly defines the terms "repeater," "port," and 
"MAU" as used in the context of this memo. This text is imprecise 


and omits many technical details. For a more complete and precise 
definition of these terms, refer to Section 9 of [7]. 
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An IEEE 802.3 repeater connects "Ethernet-like" media segments 
together to extend the network length and topology beyond what can be 
achieved with a single coax segment. It can be pictured as a star 
structure with two or more input/output ports. The diagram below 
illustrates a 6-port repeater: 


Figure 1. Repeater Unit 


All the stations on the media segments connected to a given 
repeater’s ports participate in a single collision domain. A packet 
transmitted by any of these stations is seen by all of these 
stations. 


Data coming in on any port in the repeater is transmitted out through 
each of the remaining n-1 ports. If data comes in to the repeater on 
two or more ports simultaneously or the repeater detects a collision 
on the incoming port, the repeater transmits a jamming signal out on 
all ports for the duration of the collision. 


A repeater is a bit-wise store-and-forward device. It is 
differentiated from a bridge (a frame store-and-forward device) in 
that it is primarily concerned with carrier sense and data bits, and 
does not make data-handling decisions based on the legality or 
contents of a packet. A repeater retransmits data bits as they are 
received. Its data FIFO holds only enough bits to make sure that the 
FIFO does not underflow when the data rate of incoming bits is 
slightly slower than the repeater’s transmission rate. 


A repeater is not an end-station on the network, and does not count 
toward the overall limit of 1024 stations. A repeater has no MAC 
address associated with it, and therefore packets may not be 
addressed to the repeater or to its ports. (Packets may be addressed 
to the MAC address of a management entity that is monitoring a 
repeater. This management entity may or may not be connected to the 
network through one of the repeater’s ports. How the management 
entity obtains information about the activity on the repeater is an 
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implementation issue, and is not discussed in this memo.) 


A repeater is connected to the network with Medium Attachment Units 
(MAUS), and sometimes through Attachment Unit Interfaces (AUIS) as 
well. ("MAUs" are also known as transceivers, and an "AUI" is the 
same as a 15-pin Ethernet or DIX connector.) 


The 802.3 standard defines a "repeater set" as the "repeater unit" 
plus its associated MAUs (and AUIs if present). The "repeater unit" 
is defined as the portion of the repeater set that is inboard of the 
physical media interfaces. The MAUs may be physically separate from 
the repeater unit, or they may be integrated into the same physical 
package. 


(MAU) (MAU) 


ay ee 
/ / \ \ 
(MAU) (MAU) 


Figure 2. Repeater Set 


The most commonly-used MAUs are the 10BASE-5 (AUI to thick "yellow" 
coax), l1OBASE-2 (BNC to thin coax), 10BASE-T (unshielded twisted- 
pair), and FOIRL (asynchronous fiber optic inter-repeater link, which 
is being combined into the 10BASE-F standard as 10BASE-FL). The 
draft 1OBASE-F standard also includes the definition for a new 
synchronous fiber optic attachment, known as 10BASE-FB. 


It should be stressed that the repeater MIB being defined by the IEEE 
covers only the repeater unit management - it does not include 
management of the MAUs that form the repeater set. The IEEE 
recognizes that MAU management should be the same for MAUs connected 
to end-stations (DTEs) as it is for MAUs connected to repeaters. 

This memo follows the same strategy; the definition of management 
information for MAUs is being addressed in a separate memo. 


2.1.3. Ports and Groups 


Repeaters are often implemented in modular "concentrators," where a 
card cage holds several field-replaceable cards. Several cards may 
form a single repeater unit, with each card containing one or more of 
the repeater’s ports. Because of this modular architecture, users 
typically identify these repeater ports with a card number plus the 
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port number relative to the card, e.g., Card 3, Port 11. 


To support this modular numbering scheme, this document follows the 
example of the IEEE Repeater Management draft [8], allowing an 
implementor to separate the ports in a repeater into "groups", if 
desired. For example, an implementor might choose to represent 
field-replaceable units as groups of ports so that the port numbering 
would match the modular hardware implementation. 


This group mapping is recommended but optional. An implementor may 
choose to put all of a modular repeater’s ports into a single group, 
or to divide the ports into groups that do not match physical 
divisions. 


The object rptrGroupCapacity, which has a maximum value of 1024, 
indicates the maximum number of groups that a given repeater may 
contain. The value of rptrGroupCapacity must remain constant from 
one management restart to the next. 


Each group within the repeater is uniquely identified by a group 
number in the range 1..rptrGroupCapacity. Groups may come and go 
without causing a management reset, and may be sparsely numbered 
within the repeater. For example, in a 12- card cage, cards 3, 5, 6, 
and 7 may together form a single repeater, and the implementor may 
choose to number them as groups 3, 5, 6, and 7, respectively. 


The object rptrGroupPortCapacity, which also has a maximum value of 
1024, indicates the maximum number of ports that a given group may 
contain. The value of rptrGroupPortCapacity must not change for a 
given group. However, a group may be deleted from the repeater and 
replaced with a group containing a different number of ports. The 
value of rptrGroupLastOperStatusChange will indicate that a change 
took place. 


Each port within the repeater is uniquely identified by a combination 
of group number and port number, where port number is an integer in 
the range 1..rptrGroupPortCapacity. As with groups within a 
repeater, ports within a group may be sparsely numbered. Likewise, 
ports may come and go within a group without causing a management 
reset. 


Zale Aa Internal Ports and MAUs 


Repeater ports may be thought of as sources of traffic into the 
repeater. In addition to the externally visible ports mentioned 
above, such as those with 10BASE-T MAUs, or AUI ports with external 
transceivers, some implementations may have internal ports that are 
not obvious to the end-user but are nevertheless sources of traffic 
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into the repeater. Examples include internal management ports, 
through which an agent communicates, and ports connecting to a 
backplane internal to the implementation. 


Some implementations may not manage all of a repeater’s ports. For 
managed ports, there must be entries in the port table; unmanaged 
ports will not show up in the table. 


It is the decision of the implementor to select the appropriate 
group(s) in which to place internal ports. GroupCapacity for a given 
group always reflects the number of MANAGED ports in that group. 


If some ports are unmanaged such that not all packet sources are 
represented by managed ports, then the sum of the input counters for 
the repeater will not equal the actual output of the repeater. 


2.2. Supporting Functions 


The IEEE 802.3 Hub Management draft [8] defines the following seven 
functions and seven signals used to describe precisely when port 
counters are incremented. The relationship between the functions and 
signals is shown in Figure 3. 


The CollisionEvent, ActivityDuration, CarrierEvent, FramingError, 
OctetCount, FCSError, and SourceAddress output signals defined here 
are not retrievable MIB objects, but rather are concepts used in 
defining the MIB objects. The inputs are defined in Section 9 of the 
IEEE 802.3 standard [7]. 
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+--------- + 
| Collision |--------------------- >CollisionEvent 
Collin (X)+>]|Event 
Funct sa a an ae + 
| +--------- + |Activity| 
| +------- + |Timing |->ActivityDuration 
+>|Carrier| +---->|Funct | 
[Event | +-------- + 
DataIn (X) -> |Funct |+ Ss=== PSeSsSSSsSsesssa= >CarrierEvent 
+------—- +| 
| +------- + 
+>|Framing | a >FramingError 
[Funct | +------- + 
decodedData---------- >| |+>|Octet | 
+------- +| [Count |->OctetCount 
[Funct | 
+------- + 
| +------- + 
Octet | [Cyclic | 
Stream +>|Redund. | 
| [Check |->FCSError 
[Funct | 
+------- + 
+------- + 
| | Source | 
+> | Address | ->SourceAddress 
|Funct | 
+------- + 
Figure 3. Port Functions Relationship 


Collision Event Function: 


SQE. 


The collision event function asserts the 
CollisionEvent signal when the Collin (X) 
The CollisionEvent signal remains asserted until the assertion 


variable has the value 


of any CarrierEvent signal due to the reception of the following 


event. 


Carrier Event Function: 


CarrierEvent signal when the repeater exits the IDLE state, 
and the port has been determined to be port N. 


[7], 
the CarrierEvent signal when, 
Recovery Time (Ref: 9.5.6.5 
the value II and the CollIn (N) 


[7]), 


The carrier event function asserts the 


Fig 9-2 
It deasserts 
for a duration of at least Carrier 
both the DataIn(N) variable has 
variable has the value -SQE. The 


value N is the port assigned at the time of transition from the IDLE 


state. 


Framing Function: 


The framing function recognizes the boundaries of 


an incoming frame by monitoring the CarrierEvent signal and the 
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decoded data stream. Data bits are accepted while the CarrierEvent 
signal is asserted. The framing function strips preamble and start 
of frame delimiter from the received data stream. The remaining 
bits are aligned along octet boundaries. If there is not an 
integral number of octets, then FramingError shall be asserted. The 
FramingError signal is cleared upon the assertion of the 
CarrierEvent signal due to the reception of the following event. 


Activity Timing Function: The activity timing function measures the 
duration of the assertion of the CarrierEvent signal. This duration 
value must be adjusted by removing the value of Carrier Recovery 
Time (Ref: 9.5.6.5 [7]) to obtain the true duration of activity on 
the network. The output of the Activity Timing function is the 
ActivityDuration value, which represents the duration of the 
CarrierEvent signal as expressed in units of bit times. 


Octet Counting Function: The octet counting function counts the 
number of complete octets received from the output of the framing 
function. The output of the octet counting function is the 
OctetCount value. The OctetCount value is reset to zero upon the 
assertion of the CarrierEvent signal due to the reception of the 
following event. 


Cyclic Redundancy Check Function: The cyclic redundancy check 
function verifies that the sequence of octets output by the framing 
function contains a valid frame check sequence field. The frame 
check sequence field is the last four octets received from the 
output of the framing function. The algorithm for generating an FCS 
from the octet stream is specified in 3.2.8 [7]. If the FCS 
generated according to this algorithm is not the same as the last 
four octets received from the framing function then the FCSError 
signal is asserted. The FCSError signal is cleared upon the 
assertion of the CarrierEvent signal due to the reception of the 
following event. 


Source Address Function: The source address function extracts 
octets from the stream output by the framing function. The seventh 
through twelfth octets shall be extracted from the octet stream and 
output as the SourceAddress variable. The SourceAddress variable is 
set to an invalid state upon the assertion of the CarrierEvent 
signal due to the reception of the following event. 


2.3. Structure of MIB 


Objects in this MIB are arranged into MIB groups. Each MIB group is 
organized as a set of related objects. 
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2.3.1. The Basic Group Definitions 


This mandatory group contains the objects which are applicable to 
all repeaters. It contains status, parameter and control objects 
for the repeater as a whole, the port groups within the repeater, as 
well as for the individual ports themselves. 


2.3.2. The Monitor Group Definitions 


This optional group contains monitoring statistics for the repeater 
as a whole and for individual ports. 


2.3.3. The Address Tracking Group Definitions 


This optional group contains objects for tracking the MAC addresses 
of the DTEs attached to the ports of the repeater. 


2.4. Relationship to Other MIBs 


It is assumed that a repeater implementing this MIB will also 
implement (at least) the ’system’ group defined in MIB-II [3]. 


2.4.1. Relationship to the ’system’ group 


In MIB-II, the ’system’ group is defined as being mandatory for all 
systems such that each managed entity contains one instance of each 
object in the ’system’ group. Thus, those objects apply to the 
entity even if the entity’s sole functionality is management of a 
repeater. 


2.4.2. Relationship to the ’interfaces’ group 


In MIB-II, the ‘interfaces’ group is defined as being mandatory for 
all systems and contains information on an entity’s interfaces, 
where each interface is thought of as being attached to a 

the Internet suite of protocols.) 


This Repeater MIB uses the notion of ports on a repeater. The 
concept of a MIB-II interface has NO specific relationship to a 
repeater’s port. Therefore, the ’interfaces’ group applies only to 
the one (or more) network interfaces on which the entity managing 
the repeater sends and receives management protocol operations, and 
does not apply to the repeater’s ports. 


This is consistent with the physical-layer nature of a repeater. A 


repeater is a bitwise store-and-forward device. It recognizes 
activity and bits, but does not process incoming data based on any 
packet-related information (such as checksum or addresses). A 
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repeater has no MAC address, no MAC implementation, and does not 
pass packets up to higher-level protocol entities for processing. 


(When a network management entity is observing the repeater, it may 
appear as though the repeater is passing packets to a higher-level 
protocol entity. However, this is only a means of implementing 
management, and this passing of management information is not part 
of the repeater functionality.) 


2.5. Textual Conventions 


The datatype MacAddress is used as a textual convention in this 
document. This textual convention has NO effect on either the 
syntax nor the semantics of any managed object. Objects defined 
using this convention are always encoded by means of the rules that 
define their primitive type. Hence, no changes to the SMI or the 
SNMP are necessary to accommodate this textual convention which is 
adopted merely for the convenience of readers. 


3. Definitions 


SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN 


IMPORTS 
Counter, TimeTicks, Gauge 
FROM RFC1155-SMI 


DisplayString FROM RFC1213-MIB 

TRAP-TYPE FROM RFC-1215 

OBJECT-TYPE FROM RFC-1212; 
snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 } 


-- All representations of MAC addresses in this MIB Module use, 
-- as a textual convention (i.e., this convention does not affect 
-—- their encoding), the data type: 


MacAddress ::= OCTET STRING (SIZE (6)) -—- a 6 octet address in 

-—- the "canonical" order 
-—- defined by IEEE 802.1la, i.e., as if it were transmitted least 
-- significant bit first. 


-- References 


-- The following references are used throughout this MIB: 
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Ss refers to IEEE 802.3/ISO 8802-3 Information processing 
== systems - Local area networks - Part 3: Carrier sense 
ES multiple access with collision detection (CSMA/CD) 

== access method and physical layer specifications 

== (2nd edition, September 21, 1990). 


—- [IEEE 802.3 Rptr Mgt] 


== refers to IEEE P802.3K, 'Layer Management for 10 Mb/s 


oo Baseband Repeaters, 


== ANSI/IEEE 802.3, 


Section 19,’ Draft Supplement to 


(Draft 8, April 9, 1992) 


MIB Groups 


—- The rptrBasicPackage group is mandatory. 
-- The rptrMonitorPackage and rptrAddrTrackPackage 


-- groups are optional. 


rptrBasicPackage 
OBJECT IDENTIFIER 


rptrMonitorPackage 
OBJECT IDENTIFIER 


rptrAddrTrackPackage 
OBJECT IDENTIFIER 


{ 


{ 


{ 


snmpDot3RptrMgt 1 } 


snmpDot3RptrMgt 2 } 


snmpDot3RptrMgt 3 } 


-- object identifiers for organizing the information 
-—- in the groups by repeater, port-group, and port 


rptrRptrinfo 
OBJECT IDENTIFIER 
rptrGroupiInfo 
OBJECT IDENTIFIER 
rptrPortinfo 
OBJECT IDENTIFIER 


rptrMonitorRptrinfo 
OBJECT IDENTIFIER 

rptrMonitorGroupInfo 
OBJECT IDENTIFIER 

rptrMonitorPortInfo 
OBJECT IDENTIFIER 


rptrAddrTrackRptrinfo 


McMaster & McCloghrie 


{ 


{ 


rptrBasicPackage 1 } 
rptrBasicPackage 2 } 


rptrBasicPackage 3 } 


rptrMonitorPackage 1 } 
rptrMonitorPackage 2 } 


rptrMonitorPackage 3 } 


-—- this subtree is currently unused 
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OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 } 
rptrAddrTrackGroupInfo -- this subtree is currently unused 

OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 } 
rptrAddrTrackPortiInfo 

OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 } 


SS The BASIC GROUP 

—- Implementation of the Basic Group is mandatory for all 

-—- managed repeaters. 

-- Basic Repeater Information 

-- Configuration, status, and control objects for the overall 


-- repeater 


rptrGroupCapacity OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"The rptrGroupCapacity is the number of groups 
that can be contained within the repeater. Within 
each managed repeater, the groups are uniquely 
numbered in the range from 1 to rptrGroupCapacity. 


Some groups may not be present in the repeater, in 
which case the actual number of groups present 
will be less than rptrGroupCapacity. The number 
of groups present will never be greater than 
rptrGroupCapacity. 


Note: In practice, this will generally be the 
number of field-replaceable units (i.e., modules, 
cards, or boards) that can fit in the physical 
repeater enclosure, and the group numbers will 
correspond to numbers marked on the physical 
enclosure." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2, 
aRepeaterGroupCapacity." 

::= { rptrRptrinfo 1 } 


rptrOperStatus OBJECT-TYPE 
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SYNTAX INTEGER { 


other (1), -—- undefined or unknown status 
ok(2), -- no known failures 
rptrFailure (3), -- repeater-related failure 
groupFailure (4), -—- group-related failure 
portFailure(5), —- port-related failure 
generalFailure (6) -—- failure, unspecified type 
} 
ACCESS read-only 
STATUS mandatory 


DESCRIPTION 
"The rptrOperStatus object indicates the 
operational state of the repeater. The 
rptrHealthText object may be consulted for more 
specific information about the state of the 
repeater’s health. 


In the case of multiple kinds of failures (e.g., 
repeater failure and port failure), the value of 
this attribute shall reflect the highest priority 
failure in the following order, listed highest 
priority first: 


rptrFailure (3) 
groupFailure (4) 
portFailure (5) 
generalFailure(6)." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2, 
aRepeaterHealthState." 


::= { rptrRptriInfo 2 } 


rptrHealthText OBJECT-TYPE 


SYNTAX DisplayString (SIZE (0..255)) 
ACCESS read-only 

STATUS mandatory 

DESCRIPTION 


"The health text object is a text string that 
provides information relevant to the operational 
state of the repeater. Agents may use this string 
to provide detailed information on current 
failures, including how they were detected, and/or 
instructions for problem resolution. The contents 
are agent-specific." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2, 
aRepeaterHealthText." 

::= { rptrRptriInfo 3 } 


McMaster & McCloghrie [Page 14] 


RFC 1516 802.3 Repeater MIB September 1993 


rptrReset OBJECT-TYPE 


SYNTAX INTEGER { 
noReset (1), 
reset (2) 
} 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 


"Setting this object to reset(2) causes a 
transition to the START state of Fig 9-2 in 
section 9 [IEEE 802.3 Std]. 


Setting this object to noReset(1) has no effect. 
The agent will always return the value noReset (1) 
when this object is read. 


After receiving a request to set this variable to 
reset (2), the agent is allowed to delay the reset 
for a short period. For example, the implementor 
may choose to delay the reset long enough to allow 
the SNMP response to be transmitted. In any 
event, the SNMP response must be transmitted. 


This action does not reset the management counters 
defined in this document nor does it affect the 
portAdminStatus parameters. Included in this 
action is the execution of a disruptive Self-Test 
with the following characteristics: a) The nature 
of the tests is not specified. b) The test resets 
the repeater but without affecting management 
information about the repeater. c) The test does 
not inject packets onto any segment. d) Packets 
received during the test may or may not be 
transferred. e) The test does not interfere with 
management functions. 


After performing this self-test, the agent will 
update the repeater health information (including 
rptrOperStatus and rptrHealthText), and send a 
rptrHealth trap." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3, 
acResetRepeater." 

:= { rptrRptrinfo 4 } 


rptrNonDisruptTest OBJECT-TYPE 
SYNTAX INTEGER { 
noSelfTest (1), 
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selfTest (2) 
} 


ACCESS read-write 
STATUS mandatory 
DESCRIPTION 


"Setting this object to selfTest(2) causes the 
repeater to perform a agent-specific, non- 
disruptive self-test that has the following 
characteristics: a) The nature of the tests is 
not specified. b) The test does not change the 
state of the repeater or management information 
about the repeater. c) The test does not inject 
packets onto any segment. d) The test does not 
prevent the relay of any packets. e) The test 
does not interfere with management functions. 


After performing this test, the agent will update 
the repeater health information (including 
rptrOperStatus and rptrHealthText) and send a 
rptrHealth trap. 


Note that this definition allows returning an 
‘okay’ result after doing a trivial test. 


Setting this object to noSelfTest(1) has no 


effect. The agent will always return the value 
noSelfTest(1) when this object is read." 
REFERENCE 


"Reference IEEE 802.3 Rptr Mgt, 19.2.3.3, 
acExecuteNonDisruptiveSelfTest." 
::= { rptrRptriInfo 5 } 


rptrTotalPartitionedPorts OBJECT-TYPE 


SYNTAX Gauge 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This object returns the total number of ports in 

the repeater whose current state meets all three 

of the following criteria: rptrPortOperStatus 

does not have the value notPresent (3), 

rptrPortAdminStatus is enabled(1), and 

rptrPortAutoPartitionState is autoPartitioned(2)." 
:= { rptrRptriInfo 6 } 
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—- The Basic Port Group Table 


rptrGroupTable OBJECT-TYPE 


SYNTAX SEQUENCE OF RptrGroupEntry 
ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 


"Table of descriptive and status information about 
the groups of ports." 
::= { rptrGroupiInfo 1 } 


rptrGroupEntry OBJECT-TYPE 


SYNTAX RptrGroupEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 


"An entry in the table, containing information 
about a single group of ports." 
INDEX { rptrGroupiIndex } 
:= { rptrGroupTable 1 } 


RptrGroupEntry ::= 
SEQUENCE { 

rptrGroupIndex 
INTEGER, 

rptrGroupDescr 
DisplayString, 

rptrGroupObject ID 
OBJECT IDENTIFIER, 

rptrGroupOperStatus 
INTEGER, 

rptrGroupLastOperStatusChange 
TimeTicks, 

rptrGroupPortCapacity 
INTEGER 


} 


rptrGroupiIndex OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"This object identifies the group within the 
repeater for which this entry contains 
information. This value is never greater than 
rptrGroupCapacity." 
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REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2, 
aGroupID." 

::= { rptrGroupEntry 1 } 


rptrGroupDescr OBJECT-TYPE 


SYNTAX DisplayString (SIZE (0..255)) 
ACCESS read-only 

STATUS mandatory 

DESCRIPTION 


"A textual description of the group. This value 
should include the full name and version 
identification of the group’s hardware type and 
indicate how the group is differentiated from 
other types of groups in the repeater. Plug-in 
Module, Rev A’ or 'Barney Rubble 10BASE-T 4-port 
SIMM socket Version 2.1’ are examples of valid 
group descriptions. 


It is mandatory that this only contain printable 
ASCII characters." 
:= { rptrGroupEntry 2 } 


rptrGroupObjectID OBJECT-TYPE 


SYNTAX OBJECT IDENTIFIER 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"The vendor’s authoritative identification of the 
group. This value may be allocated within the SMI 
enterprises subtree (1.3.6.1.4.1) and provides a 
straight-forward and unambiguous means for 
determining what kind of group is being managed. 


For example, this object could take the value 
1.3.6.1.4.1.4242.1.2.14 if vendor ’Flintstones, 
Inc.’ was assigned the subtree 1.3.6.1.4.1.4242, 
and had assigned the identifier 
1.3.6.1.4.1.4242.1.2.14 to its ‘Wilma Flintstone 
6-Port FOIRL Plug-in Module.’" 

::= { rptrGroupEntry 3 } 


rptrGroupOperStatus OBJECT-TYPE 
SYNTAX INTEGER { 
other (1), 
operational (2), 
malfunctioning (3), 
notPresent (4), 
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underTest (5), 
resetInProgress (6) 


} 


ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"An object that indicates the operational status 
of the group. 


A status of notPresent (4) indicates that the group 
is temporarily or permanently physically and/or 
logically not a part of the repeater. It is an 
implementation-specific matter as to whether the 
agent effectively removes notPresent entries from 
the table. 


A status of operational(2) indicates that the 
group is functioning, and a status of 
malfunctioning(3) indicates that the group is 
malfunctioning in some way." 

::= { rptrGroupEntry 4 } 


rptrGroupLastOperStatusChange OBJECT-TYPE 


SYNTAX TimeTicks 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"An object that contains the value of sysUpTime at 
the time that the value of the rptrGroupOperStatus 
object for this group last changed. 


A value of zero indicates that the group’s 
operational status has not changed since the agent 
last restarted." 

::= { rptrGroupEntry 5 } 


rptrGroupPortCapacity OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"The rptrGroupPortCapacity is the number of ports 
that can be contained within the group. Valid 
range is 1-1024. Within each group, the ports are 
uniquely numbered in the range from 1 to 
rptrGroupPortCapacity. 


Note: In practice, this will generally be the 
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number of ports on a module, card, or board, and 
the port numbers will correspond to numbers marked 
on the physical embodiment." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.5.2, 
aGroupPortCapacity." 
:= { rptrGroupEntry 6 } 


-- The Basic Port Table 


rptrPortTable OBJECT-TYPE 


SYNTAX SEQUENCE OF RptrPortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"Table of descriptive and status information about 
the ports." 


::= { rptrPortInfo 1 } 


rptrPortEntry OBJECT-TYPE 


SYNTAX RptrPortEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 


"An entry in the table, containing information 
about a single port." 

INDEX { rptrPortGroupIndex, rptrPortIndex } 

::= { rptrPortTable 1 } 


RptrPortEntry ::= 

SEQUENCE { 

rptrPortGroupIndex 

INTEGER, 
rptrPortIndex 
INTEGER, 
rptrPortAdminStatus 
INTEGER, 
rptrPortAutoPartitionState 
INTEGER, 
rptrPortOperStatus 

INTEGER 


} 


rptrPortGroupiIndex OBJECT-TYPE 
SYNTAX INTEGER (1..1024) 
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ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This object identifies the group containing the 
port for which this entry contains information." 
::= { rptrPortEntry 1 } 


rptrPortIndex OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"This object identifies the port within the group 
for which this entry contains information. This 
value can never be greater than 
rptrGroupPortCapacity for the associated group." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aPortID." 
::= { rptrPortEntry 2 } 


rptrPortAdminStatus OBJECT-TYPE 
SYNTAX INTEGER { 
enabled(1), 
disabled (2) 
} 


ACCESS read-write 
STATUS mandatory 
DESCRIPTION 


"Setting this object to disabled(2) disables the 
port. A disabled port neither transmits nor 
receives. Once disabled, a port must be 
explicitly enabled to restore operation. A port 
which is disabled when power is lost or when a 
reset is exerted shall remain disabled when normal 
operation resumes. 


The admin status takes precedence over auto- 
partition and functionally operates between the 
auto-partition mechanism and the AUI/PMA. 


Setting this object to enabled(1) enables the port 
and exerts a BEGIN on the port’s auto-partition 
state machine. 


(In effect, when a port is disabled, the value of 


rptrPortAutoPartitionState for that port is frozen 
until the port is next enabled. When the port 
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becomes enabled, the rptrPortAutoPartitionState 
becomes notAutoPartitioned(1), regardless of its 
pre-disabling state.)" 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aPortAdminState and 19.2.6.3, acPortAdminControl." 
:= { rptrPortEntry 3 } 


rptrPortAutoPartitionState OBJECT-TYPE 
SYNTAX INTEGER { 
notAutoPartitioned(1), 
autoPartitioned (2) 


} 


ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"The autoPartitionState flag indicates whether the 
port is currently partitioned by the repeater’s 
auto-partition protection. 


The conditions that cause port partitioning are 
specified in partition state machine in Section 9 
[IEEE 802.3 Std]. They are not differentiated 
here." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aAutoPartitionState." 

::= { rptrPortEntry 4 } 


rptrPortOperStatus OBJECT-TYPE 
SYNTAX INTEGER { 
operational (1), 
notOperational (2), 
notPresent (3) 
} 


ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"This object indicates the port’s operational 
status. The notPresent(3) status indicates the 


port is physically removed (note this may or may 
not be possible depending on the type of port.) 
The operational(1) status indicates that the port 
is enabled (see rptrPortAdminStatus) and working, 
even though it might be auto-partitioned (see 
rptrPortAutoPartitionState). 


If this object has the value operational(1) and 
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rptrPortAdminStatus is set to disabled(2), it is 
expected that this object’s value will soon change 
to notOperational (2) ." 

::= { rptrPortEntry 5 } 


S The MONITOR GROUP 

-- Implementation of this group is optional, but within the 
-- group all elements are mandatory. If a managed repeater 
—- implements any part of this group, the entire group shall 
—- be implemented. 


-- Repeater Monitor Information 


-- Performance monitoring statistics for the repeater 


rptrMonitorTransmitCollisions OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented every time the 
repeater state machine enters the TRANSMIT 
COLLISION state from any state other than ONE PORT 
LEFT (Ref: Fig 9-2, IEEE 802.3 Std). 


The approximate minimum time for rollover of this 
counter is 16 hours." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.2, 
aTransmitCollisions." 

::= { rptrMonitorRptriInfo 1 } 


-- The Group Monitor Table 


rptrMonitorGroupTable OBJECT-TYPE 


SYNTAX SEQUENCE OF RptrMonitorGroupEntry 
ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 


"Table of performance and error statistics for the 
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groups." 
::= { rptrMonitorGroupiInfo 1 } 


rptrMonitorGroupEntry OBJECT-TYPE 


SYNTAX Rpt rMonitorGroupEntry 
ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 


"An entry in the table, containing total 
performance and error statistics for a single 
group. Regular retrieval of the information in 
this table provides a means of tracking the 
performance and health of the networked devices 
attached to this group’s ports. 


The counters in this table are redundant in the 
sense that they are the summations of information 
already available through other objects. However, 
these sums provide a considerable optimization of 
network management traffic over the otherwise 
necessary retrieval of the individual counters 
included in each sum." 

INDEX { rptrMonitorGroupIndex } 

::= { rptrMonitorGroupTable 1 } 


RptrMonitorGroupEntry ::= 
SEQUENCE { 

rptrMonitorGroupIndex 
INTEGER, 

rptrMonitorGroupTotalFrames 
Counter, 

rptrMonitorGroupTotalOctets 
Counter, 

rptrMonitorGroupTotalErrors 
Counter 


} 


rptrMonitorGroupIndex OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"This object identifies the group within the 
repeater for which this entry contains 
information." 

::= { rptrMonitorGroupEntry 1 } 


rptrMonitorGroupTotalFrames OBJECT-TYPE 
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DESCRIPTION 
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"The total number of frames of valid frame length 
that have been received on the ports in this group 
and for which the FCSError and CollisionEvent 
signals were not asserted. This counter is the 


summation of the values of the 


rptrMonitorPortReadableFrames counters for all of 


the ports in the group. 


This statistic provides one of the parameters 
necessary for obtaining the packet error rate. 
The approximate minimum time for rollover of this 


counter is 80 hours." 
::= { rptrMonitorGroupEntry 2 } 


rptrMonitorGroupTotalOctets OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"The total number of octets contained in the valid 
frames that have been received on the ports in 
this group. This counter is the summation of the 


values of the rptrMonitorPortReadableOctets 
counters for all of the ports in the group. 


This statistic provides an indicator of the total 
data transferred. The approximate minimum time 
for rollover of this counter is 58 minutes." 


::= { rptrMonitorGroupEntry 3 } 


rptrMonitorGroupTotalErrors OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"The total number of errors which have occurred on 


all of the ports in this group. 
the summation of the values of the 


This counter is 


rptrMonitorPortTotalErrors counters for all of the 


ports in the group." 
:= { rptrMonitorGroupEntry 4 } 


-- The Port Monitor Table 
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rptrMonitorPortTable OBJECT-TYPE 


SYNTAX SEQUENCE OF RptrMonitorPortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"Table of performance and error statistics for the 
ports." 


::= { rptrMonitorPortInfo 1 } 


rptrMonitorPortEntry OBJECT-TYPE 


SYNTAX RptrMonitorPortEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 


"An entry in the table, containing performance and 
error statistics for a single port." 
INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex } 
::= { rptrMonitorPortTable 1 } 


RptrMonitorPortEntry ::= 
SEQUENCE { 

rptrMonitorPortGroupIndex 
INTEGER, 
rptrMonitorPort Index 
INTEGER, 
rptrMonitorPortReadableFrames 
Counter, 
rptrMonitorPortReadableOctets 
Counter, 
rptrMonitorPortFCSErrors 
Counter, 
rptrMonitorPortAlignmentErrors 
Counter, 
rptrMonitorPortFrameTooLongs 
Counter, 
rptrMonitorPortShortEvents 
Counter, 
rptrMonitorPortRunts 
Counter, 
rptrMonitorPortCollisions 
Counter, 
rptrMonitorPortLateEvents 
Counter, 
rptrMonitorPortVeryLongEvents 
Counter, 
rptrMonitorPortDataRateMismatches 
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Counter, 
rptrMonitorPortAutoPartitions 
Counter, 
rptrMonitorPortTotalErrors 
Counter 


} 


rptrMonitorPortGroupIndex OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"This object identifies the group containing the 
port for which this entry contains information." 
:= { rptrMonitorPortEntry 1 } 


rptrMonitorPortIndex OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"This object identifies the port within the group 
for which this entry contains information." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aPortID." 
::= { rptrMonitorPortEntry 2 } 


rptrMonitorPortReadableFrames OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This object is the number of frames of valid 
frame length that have been received on this port. 
This counter is incremented by one for each frame 
received on this port whose OctetCount is greater 
than or equal to minFrameSize and less than or 
equal to maxFrameSize (Ref: IEEE 802.3 Std, 
4.4.2.1) and for which the FCSError and 
CollisionEvent signals are not asserted. 


This statistic provides one of the parameters 
necessary for obtaining the packet error rate. 
The approximate minimum time for rollover of this 
counter is 80 hours." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
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aReadableFrames." 
::= { rptrMonitorPortEntry 3 } 


rptrMonitorPortReadableOctets OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This object is the number of octets contained in 
valid frames that have been received on this port. 
This counter is incremented by OctetCount for each 
frame received on this port which has been 
determined to be a readable frame (i.e., including 
FCS octets but excluding framing bits and dribble 
bits). 


This statistic provides an indicator of the total 
data transferred. The approximate minimum time 
for rollover of this counter is 58 minutes." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aReadableOctets." 
::= { rptrMonitorPortEntry 4 } 


Gl 


rptrMonitorPortFCSErrors OBJECT-TYP 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for each frame 
received on this port with the FCSError signal 
asserted and the FramingError and CollisionEvent 
signals deasserted and whose OctetCount is greater 
than or equal to minFrameSize and less than or 
equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 
Std). 


The approximate minimum time for rollover of this 
counter is 80 hours." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aFrameCheckSequenceErrors." 

::= { rptrMonitorPortEntry 5 } 


rptrMonitorPortAlignmentErrors OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
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DESCRIPTION 


September 1993 


"This counter is incremented by one for each frame 
received on this port with the FCSError and 
FramingError signals asserted and CollisionEvent 
signal deasserted and whose OctetCount is greater 
than or equal to minFrameSize and less than or 


equal to maxFrameSize (Ref: 


4.4.2.1). 


IEEE 802.3 Std, 
If rptrMonitorPortAlignmentErrors is 


incremented then the rptrMonitorPortFCSErrors 
Counter shall not be incremented for the same 


frame. 


The approximate minimum time for rollover of this 


counter is 80 hours." 
REFERENCE 


"Reference IEEE 802.3 Rptr Mgt, 


aAlignmentErrors." 
::= { rptrMonitorPortEntry 6 } 


rptrMonitorPortFrameTooLongs OBJECT-TYPE 


19.2.6.2, 


SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"This counter is incremented by one for each frame 
received on this port whose OctetCount is greater 
than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std). 
If rptrMonitorPortFrameTooLongs is incremented 
then neither the rptrMonitorPortAlignmentErrors 
nor the rptrMonitorPortFCSErrors counter shall be 
incremented for the frame. 
The approximate minimum time for rollover of this 
counter is 61 days." 

REFERENCE 


"Reference IEEE 802.3 Rptr Mgt, 


aFramesTooLong." 
::= { rptrMonitorPortEntry 7 } 


rptrMonitorPortShortEvents OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


TOSE 2y 


"This counter is incremented by one for each 
CarrierEvent on this port with ActivityDuration 


less than ShortEventMaxTime. 


ShortEventMaxTime is 


greater than 74 bit times and less than 82 bit 
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times. ShortEventMaxTime has tolerances included 
to provide for circuit losses between a 
conformance test point at the AUI and the 
measurement point within the state machine. 


Note: shortEvents may indicate externally 
generated noise hits which will cause the repeater 
to transmit Runts to its other ports, or propagate 
a collision (which may be late) back to the 


transmitting DTE and damaged frames to the rest of 
the network. 


Implementors may wish to consider selecting the 
ShortEventMaxTime towards the lower end of the 
allowed tolerance range to accommodate bit losses 
suffered through physical channel devices not 
budgeted for within this standard. 


The approximate minimum time for rollover of this 
counter is 16 hours." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aShortEvents." 

::= { rptrMonitorPortEntry 8 } 


rptrMonitorPortRunts OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for each 
CarrierEvent on this port that meets one of the 
following two conditions. Only one test need be 
made. a) The ActivityDuration is greater than 
ShortEventMaxTime and less than ValidPacketMinTime 
and the CollisionEvent signal is deasserted. b) 
The OctetCount is less than 64, the 
ActivityDuration is greater than ShortEventMaxTime 
and the CollisionEvent signal is deasserted. 
ValidPacketMinTime is greater than or equal to 552 
bit times and less than 565 bit times. 


An event whose length is greater than 74 bit times 
but less than 82 bit times shall increment either 
the shortEvents counter or the runts counter but 
not both. A CarrierEvent greater than or equal to 
552 bit times but less than 565 bit times may or 
may not be counted as a runt. 
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ValidPacketMinTime has tolerances included to 
provide for circuit losses between a conformance 
test point at the AUI and the measurement point 
within the state machine. 


Runts usually indicate collision fragments, a 
normal network event. In certain situations 
associated with large diameter networks a 
percentage of collision fragments may exceed 
ValidPacketMinTime. 


The approximate minimum time for rollover of this 
counter is 16 hours." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, aRunts." 
::= { rptrMonitorPortEntry 9 } 


rptrMonitorPortCollisions OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for any 
CarrierEvent signal on any port for which the 
CollisionEvent signal on this port is also 
asserted. 


The approximate minimum time for rollover of this 
counter is 16 hours." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aCollisions." 

::= { rptrMonitorPortEntry 10 } 


rptrMonitorPortLateEvents OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for each 
CarrierEvent on this port in which the Collin (X) 
variable transitions to the value SQE (Ref: 
9.6.6.2, IEEE 802.3 Std) while the 
ActivityDuration is greater than the 
LateEventThreshold. Such a CarrierEvent is 
counted twice, as both a collision and asa 
lateEvent. 
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The LateEventThreshold is greater than 480 bit 
times and less than 565 bit times. 
LateEventThreshold has tolerances included to 
permit an implementation to build a single 
threshold to serve as both the LateEventThreshold 
and ValidPacketMinTime threshold. 


The approximate minimum time for rollover of this 
counter is 81 hours." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aLateEvents." 

::= { rptrMonitorPortEntry 11 } 


rptrMonitorPortVeryLongEvents OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for each 
CarrierEvent on this port whose ActivityDuration 
is greater than the MAU Jabber Lockup Protection 
timer TW3 (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std). 
Other counters may be incremented as appropriate." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aVeryLongEvents." 
::= { rptrMonitorPortEntry 12 } 


rptrMonitorPortDataRateMismatches OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for each frame 
received on this port that meets all of the 
following conditions: a) The CollisionEvent 
signal is not asserted. b) The ActivityDuration 
is greater than ValidPacketMinTime. c) The 
frequency (data rate) is detectably mismatched 
from the local transmit frequency. The exact 
degree of mismatch is vendor specific and is to be 
defined by the vendor for conformance testing. 


When this event occurs, other counters whose 
increment conditions were satisfied may or may not 
also be incremented, at the implementor’s 
discretion. Whether or not the repeater was able 
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to maintain data integrity is beyond the scope of 
this standard." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aDataRateMismatches." 

::= { rptrMonitorPortEntry 13 } 


rptrMonitorPortAutoPartitions OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for each time 
the repeater has automatically partitioned this 


port. The conditions that cause port partitioning 
are specified in the partition state machine in 
Section 9 [IEEE 802.3 Std]. They are not 
differentiated here." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aAutoPartitions." 


:= { rptrMonitorPortEntry 14 } 


rptrMonitorPortTotalErrors OBJECT-TYPE 


SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The total number of errors which have occurred on 
this port. This counter is the summation of the 


values of other error counters (for the same 
port), namely: 


rptrMonitorPortFCSErrors, 
rptrMonitorPortAlignmentErrors, 
rptrMonitorPortFrameTooLongs, 
rptrMonitorPortShortEvents, 
rptrMonitorPortLateEvents, 
rptrMonitorPortVeryLongEvents, and 
rptrMonitorPortDataRateMismatches. 


This counter is redundant in the sense that it is 
the summation of information already available 
through other objects. However, it is included 
specifically because the regular retrieval of this 
object as a means of tracking the health of a port 
provides a considerable optimization of network 
management traffic over the otherwise necessary 
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retrieval of the summed counters." 
::= { rptrMonitorPortEntry 15 } 


aired The ADDRESS TRACKING GROUP 
—- Implementation of this group is optional; it is appropriate 
-- for all systems which have the necessary instrumentation. Ifa 


-—- managed repeater implements any part of this group, the entire 
—- group shall be implemented. 


—- The Port Address Tracking Table 


rptrAddrTrackTable OBJECT-TYPE 


SYNTAX SEQUENCE OF RptrAddrTrackEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"Table of address mapping information about the 
ports." 


::= { rptrAddrTrackPortiInfo 1 } 


rptrAddrTrackEntry OBJECT-TYPE 


SYNTAX RptrAddrTrackEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 


"An entry in the table, containing address mapping 
information about a single port." 
INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex } 
::= { rptrAddrTrackTable 1 } 


RptrAddrTrackEntry ::= 
SEQUENCE { 

rptrAddrTrackGroupIndex 
INTEGER, 

rptrAddrTrackPortIndex 
INTEGER, 

rptrAddrTrackLastSourceAddress —- DEPRECATED OBJECT 
MacAddress, 

rptrAddrTrackSourceAddrChanges 
Counter, 

rptrAddrTrackNewLastSrcAddress 
OCTET STRING 
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rptrAddrTrackGroupIndex OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"This object identifies the group containing the 
port for which this entry contains information." 
:= { rptrAddrTrackEntry 1 } 


rptrAddrTrackPortIndex OBJECT-TYPE 


SYNTAX INTEGER (1..1024) 
ACCESS read-only 

STATUS mandatory 
DESCRIPTION 


"This object identifies the port within the group 
for which this entry contains information." 
REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aPortID." 
::= { rptrAddrTrackEntry 2 } 


rptrAddrTrackLastSourceAddress OBJECT-TYPE 


SYNTAX MacAddress 
ACCESS read-only 

STATUS deprecated 
DESCRIPTION 


"This object is the SourceAddress of the last 
readable frame (i.e., counted by 
rptrMonitorPortReadableFrames) received by this 
port. 


This object has been deprecated because its value 
is undefined when no frames have been observed on 


this port. The replacement object is 
rptrAddrTrackNewLastSrcAddress." 
REFERENCE 


"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aLastSourceAddress." 
::= { rptrAddrTrackEntry 3 } 


rptrAddrTrackSourceAddrChanges OBJECT-TYPE 


SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"This counter is incremented by one for each time 
that the rptrAddrTrackLastSourceAddress attribute 
for this port has changed. 
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This may indicate whether a link is connected to a 
single DTE or another multi-user segment. 


The approximate minimum time for rollover of this 
counter is 81 hours." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aSourceAddressChanges." 

::= { rptrAddrTrackEntry 4 } 


rptrAddrTrackNewLastSrcAddress OBJECT-TYPE 


SYNTAX OCTET STRING (SIZE(0 | 6)) 
ACCESS read-only 

STATUS mandatory 

DESCRIPTION 


"This object is the SourceAddress of the last 
readable frame (i.e., counted by 
rptrMonitorPortReadableFrames) received by this 
port. If no frames have been received by this 
port since the agent began monitoring the port 
activity, the agent shall return a string of 
length zero." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.6.2, 
aLastSourceAddress." 

::= { rptrAddrTrackEntry 5 } 


-- Traps for use by Repeaters 
-- Traps are defined using the conventions in RFC 1215 [6]. 


rptrHealth TRAP-TYPE 

ENTERPRISE snmpDot3RptrMgt 

VARIABLES { rptrOperStatus } 

DESCRIPTION 
"The rptrHealth trap conveys information related 
to the operational status of the repeater. This 
trap is sent either when the value of 
rptrOperStatus changes, or upon completion of a 
non-disruptive test. 


The rptrHealth trap must contain the 
rptrOperStatus object. The agent may optionally 
include the rptrHealthText object in the varBind 
list. See the rptrOperStatus and rptrHealthText 
objects for descriptions of the information that 
is sent. 
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The agent must throttle the generation of 
consecutive rptrHealth traps so that there is at 
least a five-second gap between traps of this 
type. When traps are throttled, they are dropped, 
not queued for sending at a future time. (Note 
that ‘generating’ a trap means sending to all 
configured recipients.)" 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, 
hubHealth notification." 


rptrGroupChange TRAP-TYPE 

ENTERPRISE snmpDot3RptrMgt 

VARIABLES { rptrGroupiIndex } 

DESCRIPTION 
"This trap is sent when a change occurs in the 
group structure of a repeater. This occurs only 
when a group is logically or physically removed 
from or added to a repeater. The varBind list 
contains the identifier of the group that was 
removed or added. 


The agent must throttle the generation of 
consecutive rptrGroupChange traps for the same 
group so that there is at least a five-second gap 
between traps of this type. When traps are 
throttled, they are dropped, not queued for 


sending at a future time. (Note that ’generating’ 
a trap means sending to all configured 
recipients.)" 

REFERENCE 


"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, 
groupMapChange notification." 
::= 2 


rptrResetEvent TRAP-TYPE 

ENTERPRISE snmpDot3RptrMgt 

VARIABLES { rptrOperStatus } 

DESCRIPTION 
"The rptrResetEvent trap conveys information 
related to the operational status of the repeater. 
This trap is sent on completion of a repeater 
reset action. A repeater reset action is defined 
as an a transition to the START state of Fig 9-2 
in section 9 [IEEE 802.3 Std], when triggered by a 
management command (e.g., an SNMP Set on the 
rptrReset object). 
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The agent must throttle the generation of 
consecutive rptrResetEvent traps so that there is 
at least a five-second gap between traps of this 
type. When traps are throttled, they are dropped, 
not queued for sending at a future time. (Note 
that ‘generating’ a trap means sending to all 
configured recipients.) 


The rptrResetEvent trap is not sent when the agent 
restarts and sends an SNMP coldStart or warmStart 
trap. However, it is recommended that a repeater 
agent send the rptrOperStatus object as an 
optional object with its coldStart and warmStart 
trap PDUs. 


The rptrOperStatus object must be included in the 
varbind list sent with this trap. The agent may 
optionally include the rptrHealthText object as 
well." 

REFERENCE 
"Reference IEEE 802.3 Rptr Mgt, 19.2.3.4, hubReset 
notification." 


END 


4. Changes from RFC 1368 
(1) Added section 2.1.4, “Internal Ports and MAUs," that defines 
internal ports and clarifies how they may or may not be 


managed. 


(2) Noted that the failure list for rptrOperStatus is ordered 
highest priority first. 


(3) Clarified rptrReset description to indicate that the agent 
may briefly delay the reset action. 


(4) For rptrReset, clarified the actions that the agent should 
take after performing the reset and self-test. 


(5) For rptrNonDisruptTest, similar change to (3). 


(6) Clarified that the rptrNonDisruptTest description allows 
returning "ok" after doing only a trivial test. 


(7) Deprecated rptrAddrTrackLastSourceAddress and defined a 
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replacement object that has a zero-length value until the 
first frame is seen on the port. 


(8) Clarified that rptrHealth trap is sent after 
rptrNonDisruptTest even if repeater health information 
doesn’t change as a result of the test. 


(9) Clarified text on throttling traps. 
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7. Security Considerations 
Security issues are not discussed in this memo. 
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